Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000066_owner-urn-ietf _Thu Mar 27 19:41:26 1997.msg

Internet Message Format | 1997-04-01 | 13KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id TAA04137
    for urn-ietf-out; Thu, 27 Mar 1997 19:41:26 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id TAA04129
    for <[e-mail]>; Thu, 27 Mar 1997 19:41:22 -0500 (EST)
Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA11957  (mail destined for [e-mail]); Thu, 27 Mar 97 19:41:17 -0500
Received: from ncsa.uiuc.edu (sdgmail.ncsa.uiuc.edu [141.142.103.66])
    by newton.ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id RAA10678
    for <[e-mail]>; Thu, 27 Mar 1997 17:17:34 -0600 (CST)
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id RAA23506; Thu, 27 Mar 1997 17:12:53 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id RAA22764; Thu, 27 Mar 1997 17:12:48 -0600 (CST)
Date: Thu, 27 Mar 1997 17:12:48 -0600 (CST)
Message-Id: <[e-mail]>
To: "Karen R. Sollins" <[e-mail]>
Cc: [e-mail]
Subject: [URN] Requirements internet draft
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

Thanks for this document.  It helps me understand where we differ.

Karen R. Sollins writes:
 > Internet Draft                                          Karen R. Sollins
 > draft-ietf-urn-req-frame-01.txt                                  MIT/LCS

 >     Requirements and a Framework for URN Resolution Systems

 >  ... The URI working group
 > concluded that there was need for persistent, globally unique
 > identifiers, distinct from location or other semantic information;
 > these "names" provide identity, in that if two of them are "the same"
 > (under some simple rule of canonicalization), they identify the same
 > resource.

Regarding what the URI working group concluded, I think it is correct
to say we agree on the need for "persistent, globally unique
identifiers" but the controversial "distinct from location or other
semantic information" could be safely dropped.

 > Furthermore, the group decided that these "names" were
 > generally to be for machine, rather than human consumption.

I don't recall that.  In fact, I recall the opposite.  It is a
controversy, so it is not safe to claim we agreed on it.

 > One can imagine a variety human-friendly naming (HFN) schemes
 > supporting different suites of applications and user communities.

One can imagine a lot.  But I'd like to see some details and then
we can better guess whether the desirable features will come to pass.
Until then, we cannot rely on the future possibility of HFNs to solve
current problems.

 > Within the URI community there has been a concept used frequently that
 > for lack of a better term we will call a _hint_.  A hint is something
 > that helps in the resolution of a URN; we map URNs to hints as an
 > interim stage in accessing a resource.

How is a location hint really different from a redirection?
The term "hint" suggests that it is even weaker than a redirection.
Hints may include other things that help in resolution beside
the redirection.

 > They do not provide a
 > guarantee of access, but they probably will help in the resolution
 > process.  We must assume that most resolutions of URNs will be
 > provided by the use of locally stored hints,

Stored locally to whom?  Local to the user of a URN or local to the
document containing the URN?

 > because maintaining a
 > database of globally available, completely up-to-date location
 > information is infeasible for performance reasons.

Some people argue that it is feasible to maintain a globally
available, up-to-date database.  Depends on what you mean by
"database" and "globally available".  Is the information stored in DNS
servers a globally available database?  If you mean a single global
service, or even a single logical service that is replicated, I might
agree with you.  But the developers of the handle system would not.

If by "locally stored" you mean cached data that was previously
obtained from a global service, well, we may get better performance,
but possibly worse up-to-date-ness.

 > There are a number
 > of circumstances in which one can imagine that hints become invalid,
 > either because a resource has moved or because a different URN
 > resolver service has taken over the responsibility for resolution of
 > the URN.

Redirections may become invalid when a moved resource moves again.  If
resource servers can inform RDS services of the move of a resource,
then they can also inform known places that have redirections to the
resource.

 > Hints may be found in a variety of places.  It is generally
 > assumed that a well engineered system will maintain a set of hints for
 > each URN at each location where that URN is found.

I generally assume that "hints" will be about *collections* of URNs
and not individual URNs.  This is to get reasonable scalability.

 > In addition, for
 > those situations in which those hints found locally fail, a
 > well-engineered system will provide a fall-back mechanism for
 > discovering further hints.  It is this fall-back mechanism, an RDS,
 > that is being addressed in this document.

Hmm. "fall-back"?  I like the idea of fall-backs, of course.  But I
don't think of an RDS as the fall-back mechanism.  The RDS is the
place you get the initial information in the first place that is
cached locally, and if that data becomes obsolete, then you go back to
the RDS for the latest info.  If the RDS is merely a fall-back, then
so is every web server in the same sense, because local caches may have
obsolete info.

 > As with all hints, there
 > can never be a guarantee that access to a resource will be available
 > to all clients, even if the resource is accessible to some.  However,
 > an RDS is expected to work with reasonably high reliability, and,
 > hence, may result in increased response time.

I thought the RDS only provides more hints.  Maybe they are better,
more up-to-date hints, but they are still only hints.  No guarantees.

 > 2. Assumptions
 >
 > Based on previous internet drafts and discussion in both the URN BOFs
 > and on the URN WG mailing list, three major areas of assumptions are
 > apparent: longevity, delegation, and independence.  Each will be
 > discussed separately.

This section I mostly agree with.  I hope that is not surprising to you.

 > We expect that there will be a multi-tiered naming authority
 > delegation.

I'm glad to see that.  But then what is the difference between
multi-tiered naming authority and a hierarchical name space?  The full
hierarchical name of the naming authority would presummably appear in
the URNs.

 > Furthermore, it is difficult to imagine a non-partitioned and delegated
 > global RDS, meaning that hint discovery and resolution will be
 > partitioned and delegated.  In some RDS schemes, the delegation of
 > naming authority will form a basis for delegating the management and
 > dispensing of location information.

In fact, what is called at the top level a "*Resolver* Discovery
Service" would be a RDS Discovery Service.  Repeating that
indefinitely, we have R(DS)*.  So is it mostly a resolver or mostly a
discovery service?

 > The third assumption is independence or isolation of one authority from
 > another and, at least to some extent from its parent.  Underlying much
 > of the thinking and discussion in the URI and URN working groups has
 > been the assumption that when a component delegates authority to another
 > component, the delegatee can operate in that domain independently of its
 > peers and within bounds specified by the delegation, independently of
 > the delegator.  This isolation is critically important in order to allow
 > for independence of policy and mechanism.

But the bounds specified by the delegation may be arbitrarily
restrictive, and thus possibly not at all independent.  We have to
allow that.  For other naming authorities, there may be very few
restrictions on child authorities.  I don't think it helps much to say
anything at all about the parent-child relationship here, other than
what I just said.

 > At any given time, the owner of a namespace may choose a particular URN
 > resolver service for that delegated namespace.  Such a URN resolver
 > service may be outside the RDS service model, and just identified or
 > located by the RDS service.

Or maybe a particular RDS doesnt even know about the URN resolver or
the name space.  This may be true if it is a private resolver, private
name space or small (possibly new, possibly private) RDS.

 > 3. Requirements

I don't understand the motivation behind these RDS requirements.  If
the issue is how do we (whoever we are) decide whether a service
qualifies as an RDS, then there will always be a whole lot of
"depends" in the answer.

For example,

 >    [R1] To support evolution of mechanisms, specifically for
 >           {R1.1] a growing set of URN schemes;

Why does any RDS need to support more than the URN schemes it wants
to support?   If an RDS is going to be used only within an intranet,
for example, it only really needs to support URN schemes that are used
inside that intranet.

 > ...  Most of these requirements are not quantifiable and hence
 > conformance is a judgment call and a matter of degree.

I would be happy calling these guidelines rather than requirements.

 >           [R1.4] alternative RDS schemes active simultaneously;

Are you saying that one RDS must do something relative to the
other RDS mechanisms?  The alternative RDS mechanisms seems to be
more of an issue for clients that must choose one.

 > Second, in addition to the evolution of resolution mechanisms, we
 > expect that the community will follow an evolutionary path towards the
 > separation of location information from identification.  The URN
 > requirements document suggested this path as well, and there has been
 > general agreement in much of the community that such a separation is
 > desirable.  This is a problem that the public at large has generally
 > not understood.

Actually, I find that there is an intuitive understanding by members
of the general public that a name must be looked up somewhere, and
thus it functions like a location.

We may have trouble selling the public on a scheme that takes more
time to use, and won't pay off for dozens of years.

 > Today we see the problem most clearly with the use of
 > URLs for identification.  When a web page moves, its URL becomes
 > invalid.

When a resource disappears, its URN becomes invalid?  What does invalid
really mean?

 > ... A third alternative is that the target server supplies an
 > HTTP redirect so that the new page is provided for the client
 > automatically.  In this case, the client may not even realize that the
 > URL is no longer correct.

But the URL worked just fine - it is NOT incorrect.  Resolution does
depend on the intermediate service, but this is not different from
resolution of URNs via RDSes, other than the fact that there will be
fewer RDSes and they will be designed to be more persistent.

A new HTTP status code was added, 303, to mean "see here" (or "go
there", something like that) which causes a redirect without the
implication of "resource moved" either temporarily or permanently.

I.e. OCLC's PURL service is a perfectly adequate persistent URN
resolution service, if you trust that OCLC will be around long enough,
or if you can trust that clients will know where to lookup the PURL
resolver service after OCLC gets swallowed by Microsoft (there is no
basis in that rumor).

 > The real problem with both of these latter
 > two situations is that they only work as long as the forwarding
 > pointer can be found at the old URL.  Location information, was
 > embedded in the identifier, and the resolution system was designed to
 > depend on that location information being correct.

Yes and no. I won't repeat my whole argument here.  Ask in private
email if you want to continue this.

 > To the extent that an RDS scheme supports the separation of global
 > identification from location information it will be encouraging the
 > longer utility of the identities.

Important principle:

It is not the separation of global identification from location
information that can give identifiers their longevity.  The longevity
of identifiers comes from the persistence of the resolution (or
discovery) services together with the ability to return a redirection
as opposed to the resource itself.

(We discussed all-identifiers-are-relative previously.)

I don't have time to finish commenting on the rest of the document
at this time.  And the above is probably sufficient for now.

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/